This PR contains the following changes:

• Dev changes (early exit when userLocation is undefined - gkartalis)

Generated by 🚫 dangerJS against 02b296a

Summary

Guards the map user-location button against undefined/null coordinates. Adds an isValidLatLng type predicate used both to gate the button render and its setCamera call, and tightens onUserLocationUpdate to require numeric latitude/longitude before storing a location. Also drops a STRICTNESS_MIGRATION escape hatch.

The fix targets the right spot: userLocation is seeded from viewer.city?.coordinates (GlobalMap.tsx:85-86), and LatLng.lat / LatLng.lng are both nullable Float in the schema (data/schema.graphql:22546-22549), so the old !!userLocation check happily passed an object of nulls into centerCoordinate.

Issues Found

No blocking issues.

• 🟢 isValidLatLng(location: any) (GlobalMap.tsx:604) — see inline. The caller type is known; { lat?: number | null; lng?: number | null } | null | undefined narrows the same way without any.
• 🟢 Redundant !! (GlobalMap.tsx:151) — isValidLatLng already returns a boolean.
• 🟢 No test. src/app/Scenes/Map/__tests__/ only has Bucket.tests.ts and exhibitionPeriodParser.tests.ts, so GlobalMap.tsx is untested and nothing pins this behavior. Exporting isValidLatLng and adding a few cases (undefined, { lat: null, lng: null }, { lat: 0, lng: 0 }) is cheap and would catch a regression where someone swaps the guard back for a truthiness check. The lat: 0 case matters — a naive !location.lat rewrite would break the equator and prime meridian.

Areas Reviewed

Bugs and edge cases: the typeof === "number" checks correctly accept 0, which a truthiness check would drop. onUserLocationUpdate now rejects strictly more inputs than before (!location || !location.coords, plus numeric lat/lng), so no path that previously stored a good location is lost. Nothing else in the file reads userLocation coordinates; highlight={userLocation === currentLocation} at line 154 is reference equality and unaffected.

Performance and architecture: nothing notable, the helper is a module-level pure function.

Questions for Author

1. The description says "No UI changes", but the render condition went from !!userLocation to !!isValidLatLng(userLocation). Those differ when a city has coordinates: { lat: null, lng: null }: the button used to render (and crash on tap) and now hides. That is the right call, just worth stating in the description so QA is not surprised by a missing button in a data-broken city.
2. The Android box is unchecked, and the new comment at lines 344-346 attributes the empty-coords updates to the native side. Since onUserLocationUpdate is driven by the platform location provider, a quick Android run would confirm the guard does not swallow legitimate first fixes there. Do you have a repro city or device for the Sentry crash to check against?